Changes look good to me. I don't see any negative impact for mio here. So, r=me once you're comfortable @fiveop.

EDIT: I missed the minor, good interface change. Probably worth testing mio with this before merging and prepping changes there if required.

I added readers for EpollEvent's fields and made the constructor public (doh!). Now, mio can be easily adapted to the changes (see https://github.com/fiveop/mio/tree/nix_epoll_change).

Seems fine to me. There's a bit of possible "conventions" work on the flags and stuff, but that can wait. We should perhaps let @carllerche weigh in. Also I imagine epoll_create1 could be handy for mio, since it's unlikely you want to propagate epoll fds to children.

He had his chance :) But seriously, after having tested adapting mio code to the change, I don't really see a problem.

I would like to have it merged after we have a new dev version.

Oh I missed that he was pinged already. In that case, @homu r+

📌 Commit 584794d has been approved by kamalmarhubi

@homu r-

Can we at least export EPOLL_CLOEXEC here, or add it as a single-element flags type for the second arg to epoll_create1?

Naming will get complicated from conventions view as there are all the EPOLLET EPOLLIN flags, as well as this single EPOLL_CLOEXEC flag.

I opted for EpollFlags and EpollCreateFlags. The latter breaks convention, but there has to be a break in convention :)

I tried to use libc_bitflags for EpollFlags, but EPOLLEXCLUSIVE is not available very widely, even on different linux platforms.
That the constants have type c_int in libc, but the field epoll_event.events has type uint32_t is another problem, when using a libc_bitflags macro (or the constants from libc in general).

But that's for another PR!

Looks good to me. Since we recently cut a release, this is probably a pretty good time to get the change in so we can integrate mio changes into upstream in preparation.

@homu r+

📌 Commit 2b0c991 has been approved by posborne

⚡ Test exempted - status